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The  Challenges  of 
Being  Agile  in  DoD 

William  Broadus 


n  today's  acquisition  environ¬ 
ment,  it  no  longer  is  unusual  for 
your  program  to  award  a  product 
or  service  development  contract 
in  which  the  vendor  intends  to  uti¬ 
lize  "Agile  Methods"  for  its  software 
development  efforts.  In  fact,  the  of¬ 
ficial  push  for  Agile  within  the  De¬ 
partment  of  Defense  (DoD)  came 
from  Congress  in  Section  804  of  the 
Fiscal  Year  2010  National  Defense 
Authorization  Act:  Implementation 
of  New  Acquisition  Process  for  In¬ 
formation  Technology  Systems. 

This  section  directed  the  Department  to  report  to  Congress  on  how  DoD 
planned  to  meet  the  intent  of  the  law.  The  key  elements  of  the  response 
from  the  Office  of  the  Secretary  of  Defense  ("A  New  Approach  for  Deliver¬ 
ing  Information  Technology  Capabilities  in  the  Department  of  Defense," 
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November  2010)  focused  on  the  following:  (1)  Deliver  Early  and 
Often,  (2)  Incremental  and  Iterative  Development  and  Test¬ 
ing,  (3)  Rationalized  Requirements,  and  (4)  Flexible/Tailored 
Processes  (see  Figure  1).  Also,  both  the  DoD  Chief  Information 
Officer  in  the  Department's  modernization  plans  and  the  White 
House  CIO  in  the  FY  2013  budget  priorities  clearly  identify  the 
government's  need  to  establish  processes  and  "agile  teams"  to 
achieve  secure,  efficient,  and  effective  IT  for  DoD. 

For  most  programs,  using  Agile  is  approaching  new  territory, 
full  of  unfamiliar  processes,  lacking  clear  alignment  to  existing 
expectations,  and/or  one  in  which  program  stakeholders  are 
unprepared  to  adapt  to  their  changing  roles.  As  is  illustrated 
in  Figure  2,  researchers  reviewing  Agile  projects  and  pro¬ 
grams  within  the  DoD  environment  have  identified  a  number 
of  key  barriers  that  could  create  major  challenges  to  achiev¬ 
ing  successful  outcomes.  Unsurprisingly,  these  challenges  are 
rooted  in  the  differences  between  the  traditional  acquisition 
methods  of  DoD  and  those  practiced  within  the  Agile  com¬ 
munity.  Programs  intent  upon  success  must  realize  that  the 
benefits  of  Agile  can  be  achieved  in  the  DoD  environment  only 
through  thoughtful  planning,  preparation,  and  implementa¬ 
tion  focused  on  acknowledging  differences,  adapting  to  the 
new  methodologies,  and  not  expecting  the  Agile  approach 
to  fit  into  an  "acquisition  development  box."  As  one  expert  in 
the  field  stated, ". . .  to  become  Agile  is  to  migrate  from  Work 
Breakdown  Structures  (WBSs)  to  backlogs  and  from  Gantt 
charts  to  burndown  charts." 


Multiple  studies  of  the  DoD  5000  series  by  organizations 
familiar  with  DoD  acquisition  and  Agile  Methodologies  have 
concluded  there  are  no  direct  policy  or  practice  issues  that 
would  preclude  or  limit  the  use  of  Agile  methods  within  the 
DoD.  A  very  important  conclusion  of  these  studies  on  Agile 
methods  is  that  they  can  provide  both  tactical  and  strategic 
benefits  for  the  organization.  The  tactical  benefits  of  lower 
cost  within  schedule  and  increasing  quality  are  important. 
However,  the  strategic  benefits  of  being  responsive  and  being 
able  to  adjust  to  the  current  situation  more  rapidly  might  be 
of  even  greater  value. 

Adopting  Agile  within  the  DoD  still  presents  a  number  of 
concerns  even  with  the  additional  direction  provided  by 
recent  policies  and  statutory  changes.  The  key  challenge, 
which  will  be  addressed  from  numerous  perspectives  in  this 
article,  is  how  to  implement  a  new  set  of  management  and 
technical  approaches  necessary  for  the  advantages  of  Agile 
to  be  fully  leveraged. 

Agile  in  Context 

In  this  article,  the  term  "Agile"  will  serve  as  an  overarching 
term  to  represent  all  forms  of  iterative  development  whether 
Scrum,  Lean  Software  Development,  extreme  programming 
(XP),  or  others.  The  discussion  will  focus  on  the  common  root 
cause  challenges  and  not  the  unique,  specific  details  of  the 
various  methodologies.  The  idea  for  "Agile"  began  12  years 
ago  when  a  small  group  of  software  gurus  brought  forth  the 


Figure  1.  Business  Capability  Lifecycle  Acquisition  Business  Model* 
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Guiding  Principles: 

Key  Attributes: 

•  Deliver  early  and  often 

•  Streamlined  capability  documentation 

•  Incremental  and  iterative  development  and  testing 

•  Streamlined  governance  and  tiered  accountability 

•  Rationalized  requirements 

•  Independent  risk  assessment 

•  Flexible/tailored  processes 

•  Flexibility  in  capability  implementation  strategies 

•  Knowledgeable  and  experienced  IT  Workforce 

•  Emphasis  on  the  use  of  mature  technologies 

•  Use  of  “time  constrained”  process  management  and  program  execution 

•  Capability  delivery  in  increments  of  18  months  or  less 

•  User  and  test  communities  engagement  throughout  the  life  cycle 

*OSD  Report  to  Congress  #13744-10,  “A  New  Approach  for  Delivering  Information  Technology  Capabilities  in  the  Department  of  Defense,”  November  2010  (Pursuant  to  Section 
804  of  the  National  Defense  Authorization  Act  for  Fiscal  Year  2010). 
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Figure  2.  Approach  to  Project  Variables 


Traditional  Approach  Agile  Approach 


Customers  tend  to  remember  slipped  dates  more  than 
they  remember  slipped  features  or  functionality 


"Agile  Manifesto"  (2000),  posing  a  radical 
approach  to  software  development. 

Agile  is  as  much  a  philosophy  as  a  modern 
development  methodology.  This  philosophy 
focuses  on  value  to  the  customer  and  effi¬ 
ciency  in  the  approach  to  delivery,  a  key  fric¬ 
tion-point  when  working  within  the  signifi¬ 
cant  structure  of  the  typical  DoD  program. 

Agile  focuses  on  better  collaboration,  satis¬ 
fied  customers  (short-term  feedback)  and 
higher-quality  software.  This  approach 
has  gained  significant  "traction"  against 
more  traditional  waterfall  or  "phase-gate" 
development  processes,  which  are  the  tra¬ 
ditional  DoD  planning  paradigms  as  high¬ 
lighted  in  Figure  3.  The  generally  agreed-to 
benefits  a  program  can  achieve  by  incorpo¬ 
rating  Agile  include: 

■  Ability  to  stay  nimble  and  responsive  to  constantly  chang¬ 
ing  customer  needs 

■  Faster  time  to  market  of  products  (reduced  cycle-time) 

■  Meaningful  collaboration  between  all  stakeholders 

Agile  requires  new  skills  by  all  those  involved  in  the  process  in 
order  to  be  successful;  development  team,  customers,  product 
owners,  and  other  stakeholders.  This  point  and  its  implications 
will  be  addressed  in  several  ways  later  in  the  article. 

Questions  that  arise  from  non-Agile  aligned  stakeholders  will 
include  items  such  as: 

■  What  are  we  really  building?  What  happens  to  the  require¬ 
ments? 

■  How  do  we  keep  everyone  in  the  loop  when  we're  not  in  the 
same  office  for  the  "daily  standup"?  (An  Agile  process  of 


daily  discussions  on  planning  and  implementation  activities 
that  is  significant  to  the  development  process  and  feedback 
to  all  involved). 

■  How  do  we  control  scope  and  communicate  changes  when 
they  occur? 

■  How  do  we  know  what  the  development  team  will  deliver  at 
the  end  of  the  Sprint?  (A  basic  unit  of  development  in  Scrum 
that  lasts  for  "time-boxed"  or  restricted  durations  of  from 
24  hours  to  an  entire  month.) 

Given  the  above  context  for  Agile,  the  remaining  portion  of 
the  article  will  identify  and  discuss  the  likely  barriers  and  chal¬ 
lenges  a  DoD  program  will  face  in  embracing  Agile  as  a  both 
a  philosophical  and  developmental  paradigm. 

Barriers  and  Challenges 

This  article  will  use  a  draw  upon  numerous  research  ef¬ 
forts  to  identify  and  discuss  key  focus  points  for  the  gov- 


Figure  3.  Traditional  Waterfall  vs.  Agile 


Process 

Waterfall  Approach 

Agile  Approach 

Planning  and  Scheduling 

Pert/Gantt,  detailed  and  upfront;  fix  scope, 
estimate  time,  and  resources 

Release  and  iteration  plans  updated 
throughout;  fix  date,  estimate  scope 

Requirements  and  Design 

Detailed  and  upfront 

Continuous,  emergent,  last  responsible 
moment 

Implementation 

Code  in  parallel,  follow  plan,  change  control, 
deliver  at  end  of  phase;  test  afterward 

Code  and  test;  deliver  incremental  working 
software  each  iteration 

Test/QA 

Detailed  test  plans;  test  after  implementa¬ 
tion  phase 

Continuous  integration,  build,  and  test 

Management  Culture 

Hierarchical  and  contractual,  "command  and 
control" 

Servant  leadership,  collaboration,  flat 
organization 

Measures  of  Success 

Conformance  to  plan  or  contract 

Working  software,  satisfied  customers 
and  team 

Adapted  from:  Leffingwell,  D.,  Scaling  Software  Agility ,  Addison-Wesley,  2007. 
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ernment  and  vendor  team  to  consider  in  incorporating 
Agile  methods  into  their  overall  acquisition  strategy  and 
programmatic  approach. 

The  DoD  Life  Cycle  and  Major  Events 

Some  of  the  DoD  life-cycle  phases  lend  themselves  to  the 
use  of  Agile  methods  better  than  others.  It  is  important  to 
plan  on  how  you  will  include  Agile  processes  into  your  con¬ 
tractually  binding  documents  (request  for  proposals,  state¬ 
ments  of  objective  or  work,  etc.)  to  achieve  the  benefits  of 
those  processes  and  practices.  An  area  where  this  plan¬ 
ning  is  most  critical  is  setting  proper  expectations  around 
technical  review  events  such  as  the  Preliminary  and  Critical 


Agile  Knowledge  and  Training 

The  concepts  of  Agile  are  based  upon  sound  practices  for 
software  development  and  therefore  are  not  new  in  nature. 
This  drives  a  demand  for  training  for  all  the  government 
program  office  as  appropriate  for  their  role.  Support  for 
this  will  require  both  upfront  and  ongoing  planning  and 
resources.  Vendors  may  also  need  to  take  part  in  some 
of  this  training  in  order  to  understand  how  to  improve  the 
interface  between  their  Agile  approaches  and  the  govern¬ 
ment's  management  systems.  Having  an  "Agile  advocate" 
on  the  government  program  team  who  is  empowered  to 
work  with  both  the  government  and  vendor  teams  is  con¬ 
sidered  a  best  practice. 


For  most  programs,  using  Agile  is  approaching  new  territory, 
full  of  unfamiliar  processes,  lacking  clear  alignment  to  existing 

expectations,  and/or  one  in  which  program  stakeholders  are 
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unprepared  to  adapt  to  their  changing  roles. 
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Design  Reviews  (PDRs  and  CDRs).  Agile  methods  do  not 
deliver  the  types  of  supporting  documentation  expected  at 
these  events.  They  do  deliver  working  prototypes  that  may 
provide  for  a  subset  of  stated  requirements  in  the  form  of 
usable  software.  Clearly,  the  expectations  and  criteria  for 
acceptance  will  need  to  be  established  and  reflected  in  the 
contract  language.  The  primary  point  is  that  Agile  produces 
the  final  product  iteratively,  and  this  will  require  managing 
expectations  related  to  acceptance  and  decision-making 
activities  to  ensure  compatible  outcomes. 

Your  Team  Environment 

A  central  concept  to  Agile  methods  is  the  use  of  small,  fo¬ 
cused,  cross-functional  teams.  As  a  practice,  testing  is  done 
concurrently  with  the  development  and  iteration  efforts.  This 
requires  significant  access  to  the  end  users  (or  likely  their 
designated  representatives)  throughout  this  process.  This  will 
require  the  members  of  the  government  team  (the  end-user 
representatives)  to  understand  and  participate  in  this  signifi¬ 
cantly  more  hands-on  approach  to  development. 

“End-User"  Access  and  Involvement 

A  key  tenet  of  the  "Agile  Manifesto"  is  the  concept  of  "Cus¬ 
tomer  Collaboration  over  Contract  Negotiation."  The  primary 
way  this  is  accomplished  is  through  continuous  contact  be¬ 
tween  the  Agile  development  team  and  the  end  user.  This 
requires  the  government  and  vendor  to  agree  upon  an  appro¬ 
priate  proxy  who  will  be  the  voice  of  the  end  user  in  their  daily 
interactions  with  the  Agile  team.  This  practice  will  require 
the  program  office  to  plan  and  conduct  ongoing  activities 
that  are,  fundamentally,  tailored  Early  Operational  Assess¬ 
ments  (EOAs). 


Balancing  Stakeholder  Insight/Oversight 

DoD  programs  rely  heavily  upon  milestone  reviews,  docu¬ 
ments,  reports,  and  selected  metrics  to  monitor  and  assess 
vendor  progress  and/or  assess  aspects  of  the  proposed  tech¬ 
nical  solution. 

Agile  methods  use  a  similar  process.  However,  the  documen¬ 
tation  generated  for  Agile  is  tailored  to  meet  the  minimum 
necessary  for  the  programmatic  and  technical  needs  of  the 
development  team.  This  documentation  normally  is  insuf¬ 
ficient  to  support  typical  DoD  milestone/capstone  events. 
During  the  proposal  and  negotiation  processes,  what  is  ac¬ 
ceptable  for  the  program  and  will  work  with  the  Agile  envi¬ 
ronment  needs  to  be  determined  and  captured  in  the  con¬ 
tract.  The  tailoring  process  to  meet  this  need  should  focus  on: 

■  Confirming  that  all  participants  are  truly  program  stake¬ 
holders  and  are  committed  to  achieving  the  contract 
outcomes 

■  Establishing  how  all  regulatory  and  policy  documentation 
that  does  not  directly  contribute  to  Agile  will  be  developed 

■  Reaching  clear  agreement  on  the  intent  and  content  of  all 
contract  elements 

■  Achieving  all  the  nontechnical  requirements  placed  upon 
the  program 

The  analogy  frequently  used  to  explain  oversight  within  the 
Agile  community  originated  with  military  leaders  in  the  field 
and  is  called  "Commander's  Intent."  With  Agile,  it  is  all  about 
the  intent  when  it  comes  to  planning.  If  the  plan  does  not 
work  as  expected,  the  team  will  alter  its  plans  while  clearly 
keeping  the  original  intent  in  mind.  Agile  programs  tend  to  be 
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less  formal  contractually,  but  are  highly  disciplined  in  process 
and  practice. 

Team  Composition 

Agile  development  team  composition  is  different  than  tra¬ 
ditional  development  teams.  In  this  case,  the  government 
program  team  needs  to  flex  toward  the  vendor  and  strongly 
consider  changing  its  composition.  The  two  positions  that 
would  be  necessary  to  add  to  the  government  team  are  the 
Agile  Advocate  and  the  end-user  representative.  The  end-user 
representative  must  represent  the  software/system  user's 
perspective  but  also  have  the  technical  authority  from  the 
Procurement  Contracting  Officer  to  direct  contractor  activi¬ 
ties  within  specific  limits.  Both  these  key  government  team 
positions  require  that  those  serving  in  them  possess  skills  in 
modern  software  development  approaches  associated  with 
Agile  as  well  as  knowledge  and  application  of  best  acquisition 
practices.  Staffing  these  two  roles  likely  will  be  one  of  the  most 
difficult  challenges  for  the  government  to  overcome. 

Shitting  Cultures 

All  organizations  have  a  culture  based  upon  their  knowledge, 
beliefs,  displayed  behaviors,  and  traits.  In  the  traditional  DoD 
organization,  the  focus  is  on  following  the  plan  with  minimal 
change.  In  Agile,  the  focus  is  on  adapting  successfully  to  in¬ 
evitable  change.  The  goal  is  not  just  to  "do  Agile"  but  to  "be 
Agile."  Simply  utilizing  an  Agile  process,  and  following  each 
step  dutifully,  will  yield  some  benefit.  However,  if  being  Agile 
is  the  goal,  "a  culture  of  agility"  needs  to  be  created. 

Integration  and  Test 

Agile  uses  a  significantly  different  approach  to  integration  and 
testing  than  is  employed  in  most  DoD  development  programs. 
In  Agile,  integration  and  test  are  continuous  activities,  contrary 
to  the  traditional  approach  where  they  are  completed  at  the 
end  of  a  release  cycle.  This  does  not  negate  the  need  to  have 
an  independent  external  team  conduct  a  system  assessment 
for  effectiveness  or  suitability  as  is  done  in  Operational  Test¬ 
ing.  What  this  continuous  integration  and  test  approach  does 
promote  is  a  reduction  in  the  risk  as  more  issues  are  identified 
earlier  in  the  life  cycle.  Since  Agile  puts  the  activity  of  valida¬ 
tion  (involvement  of  the  end-user  representative)  before  the 
activity  of  verification,  there  is  less  risk  that  the  end  user  will 
not  accept  the  product  upon  delivery. 

Conclusions  and  Summary 

Currently  within  DoD  there  are  three  main  reasons  programs 
are  shifting  toward  an  Agile  approach  to  development:  insuf¬ 
ficient  progress  and  performance  using  the  traditional  model, 
inability  to  provide  urgent  responses  to  evolving  mission  needs, 
and  the  advent  of  Section  804  of  the  National  Defense  Autho¬ 
rization  Act  for  Fiscal  Year  2010.  In  the  case  of  Section  804, 
there  are  four  directives  on  evolving  the  design  approach  for 
software  information  systems:  (A)  early  and  continual  involve¬ 
ment  of  the  user;  (B)  multiple  rapidly  executed  increments 
or  releases  of  capability;  (C)  early,  successive  prototyping  to 
support  an  evolutionary  approach;  and  (D)  a  modular  open- 


systems  approach.  Agile  methods  are  very  compatible  with 
achieving  all  four  of  these  directives  much  more  than  tradi¬ 
tional  acquisition  practices. 

Observations  gathered  from  government  teams  that  have 
already  begun  embracing  Agile  methods  in  their  programs 
have  identified  several  very  encouraging  common  themes. 
These  include: 

■  Increased  sense  of  accomplishment  for  delivered  releases 
due  to  clear  alignment  to  user  needs 

■  Shorter  time  between  initiation  and  delivery  to  the  end 
users 

■  Positive  user  feedback  that  clearly  highlighted  the  value  of 
Agile  approach 

■  Consistent  and  predictable  ability  to  meet  end-user 
expectations 

■  Prior  inability  to  deliver  above  values  with  previous 
approaches 

Upon  reviewing  the  research  on  successes  and  issues  asso¬ 
ciated  with  adopting  Agile  methods  and  the  organizational 
change  management  necessary  to  implement  them,  the  fol¬ 
lowing  are  offered  as  an  initial  set  of  "takeaways"  for  the  plan¬ 
ning  process  by  the  government  team: 

■  Understand  your  "adopters":  Determine  the  characteristics 
of  the  individuals  and  the  group  who  will  be  affected  by  mov¬ 
ing  to  Agile  methods.  The  key  to  success  is  understanding 
how  to  work  on  Agile  in  a  traditional  environment. 

■  Allow  the  time  for  change  to  work:  Consider  the  time  neces¬ 
sary  to  implement  your  Agile  approach  and  don't  be  unreal¬ 
istic  with  your  schedule.  Consider  adopting  an  iterative  ap¬ 
proach  to  rolling  out  your  Agile  methods  and  identifying  the 
key  roles  of  Agile  Advocate  and  end  user  representatives. 

■  Understand  the  risks  associated  with  adopting  Agile:  Focus 
is  on  the  knowledge,  skills,  and  practices  of  the  involved 
stakeholders.  Consider  leaning  heavily  on  external  training 
and  coaching  to  mitigate  your  risk  in  this  area. 

Implementing  Agile  methods  in  your  government  program 
can  provide  the  benefits  of  being  responsive  and  able  to  ad¬ 
just  more  rapidly  to  changes  in  the  current  environment  than 
when  relying  upon  more  traditional  methods.  A  government 
team  must  overcome  significant  challenges  and  barriers  to 
effectively  adopt  Agile.  These  include  dealing  with  the  de¬ 
mands  of  the  acquisition  life  cycle,  assessing  and  addressing 
the  composition  and  training  needs  of  the  team,  understand¬ 
ing  clearly  the  needs  of  the  end  user,  effectively  satisfying  the 
needs  of  stakeholders  related  to  programmatic  insights,  ef¬ 
fectively  integrating  multiple  testing  approaches,  as  well  as 
exercising  the  management  and  leadership  necessary  to  drive 
culture  change  while  buildingteam  trust.  Agile  implementation 
requires  a  significant  undertaking  but  holds  the  potential  for 
significant  positive  future  outcomes  for  your  team.  & 


The  author  can  be  contacted  at  william. broadus@dau.mil. 
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